The present invention relates to the field of memories in general and the management of memory access in particular.
The open systems interconnection (OSI) reference model adopted by the International Standards Organisation (ISO) provides a structured architectural model for inter-computer communications.
Packet networks such as internet protocol (IP) are typically organised into a layered structure following the OSI 7 layer reference model. According to this model layer 1 comprises the physical medium, layer 2 is the link layer (point-to-point framing, e.g. IEEE 802 or media access control (MAC)), layer 3 is the network layer (e.g. IP), layer 4 is the transport layer (e.g. UDP, TCP, ICMP, etc.) and layer 5 is the session layer (e.g. RTP).
The above abbreviations are explained in the IETF RFC publications referred to below.
The upper layer, layer 5 adds a header to the payload or data being transmitted across the network. Each successively lower layer treats the payload and header of the immediately higher layer as its own payload and adds its own header to this payload. The combination of the original (data) payload with the headers will be referred to here as a “packet”.
The internet protocol (IP) is a network layer protocol, i.e. corresponding to layer 3 of the OSI reference model. The IP layer is concerned with addressing information and control information that is included in the header of a packet to enable that packet to be successfully routed.
The layer 3 header is often referred to as the “internet protocol” or IP header, whereas the layer 4 header is referred to as the “protocol” header. It is to be noted that these are distinct entities and for the avoidance of confusion the terms ‘layer 3 header’ and ‘layer 4 header’ will be used here.
A typical internet protocol communications network is divided into secure and insecure areas. A secure area is protected from unauthorized access by users within insecure areas by a so-called firewall. This is a node that acts at the boundary between a secure and an insecure area to filter traffic coming into the secure area from the insecure area and vice versa. A basic principle of filtering is to hide the actual IP addresses and ports of the secure network from the insecure network. The ‘ports’ are not physical ports but fields in a header of a packet that can be used as address extensions. Two such ports are defined both occurring in the layer 4 header: a source port and destination port. Either or both ports may be used in this way, and for simplicity the term “port” is used in the following to cover all possibilities. The initiator of the call is unaware of the real destination address and port related to the destination node. When a call to a node in the secure network is initiated from the insecure network, the caller uses a “dummy” destination address and port available on the firewall instead of the actual destination address and port related to the true destination node.
Although the port may typically be used to identify the type of session layer, the firewall treats the port as an extension of the destination address. On receipt of a valid call (i.e. a call that is not rejected by the firewall) from the insecure network, the firewall translates the received destination address and port used by the caller into the actual destination and address of the called node within the secure network. For traffic in the opposite direction, the translation is effected in reverse.
In the layer 3 header, the source of a packet is identified by the source address, destination address, protocol and fragment identification fields. The source address is the address of the originator of the packet; and is made up of a network number (which forms the more significant part) and a node number (which form the less significant part): the destination address is the address of the intended recipient of the packet, the fragment offset is the offset in numbers of 8 bit octets relative to the start of the original layer 3 payload data in the fragment; the fragment identification field holds a value created by the source to characterise a packet so as to aid in reassembling the fragments of that packet; the protocol field identifies the type of layer 4 header (e.g. UDP, TCP, ICMP, etc.) associated with that packet. In order to provide an acceptable level of security, the firewall also needs to be able to identify the application associated with a particular Packet. Hence, in addition to the above layer 3 fields, the firewall needs access to the port of the layer 4 header.
When fragments are reassembled at the destination of the call, they are reassembled per application as indicated by the port as well as per source as indicated by the layer 3 header fields.
A problem arises in trying to identify the source of an incoming call from the insecure network due to fragmentation of packets. A layer 3 packet may be up to 64 Kilobytes long, however this packet plus the layer 3 header form the payload for the MAC (layer 2) frames which can only handle ‘fragments’ of up to 1500 bytes in length. Hence a typical layer 3 Packet will be transported in a plurality of fragments or layer 2 frames. To make matters worse, the fragments related to a particular packet may arrive at the media firewall in a random order. In filtering the incoming traffic, the firewall needs to be able to identify the source of each fragment.
Each layer 2 frame starts with the layer 2 header followed by the layer 3 header from the layer 3 packet followed by a section of the layer 3 payload. The layer 4 header forms part of the layer 3 payload which is divided into sections, each section being carried in a different layer 2 frame. Although each layer 2 frame contains a copy of the layer 3 header, only the first frame in a packet should contain a copy of the layer 4 header. Hence the port field should only exist in one of the fragments of a packet.
If the port field does occur in practice in more than one fragment this is an indication of an attack on the secure network. There is therefore a need to store the contents of the port field contained in the first fragment for each source identified for the duration of a packet so that it may be used in combination with the layer 3 header fields listed above to check subsequent fragments relating to the same packet.
The port field should occur in the first fragment received for a particular packet and this fragment should not overlap subsequent fragments. If this is not the case, the attacking fragments will be discarded by the firewall. Detailed operations of a firewall filter are given in Internet Engineering Taskforce (IETF) requests for comment RFC 1858 “security considerations for IP fragment filtering” October 1995.
Although described here in detail with reference to network layer header Version 4 (IPv4), the present invention is also applicable to network layer version 6 (IPv6) header format: the main difference between these two forms of header with respect to the present invention being that the Version 4 fragment offset and fragment identification fields are not present in the Version 6 header. The Version 6 header has a “next header” field which may point to a succession of further headers eventually leading to a header which comprises fragment offset and fragment identification fields. The firewall filter process would recognise that it was dealing with a Version 6 header and would access the fragment offset and identification fields in the relevant further header.
Details of the operation of the internet protocol in general and of the Version 4 and Version 6 headers in particular are contained in IETF requests for comment RFC 791 “DARPA Internet Programme Protocol Specification” September 1981 and RFC 2460 “Internet Protocol, version 6 (IPv6) specification” December 1998, respectively.
Not all types of layer 4 header contain the port field. Whereas transmission control protocol (TCP) and user datagram protocol (UDP) layer 4 headers do contain the port field, other forms of Layer 4 protocol (e.g. network management protocols) have no equivalent to the port field and therefore identification of the source has to be achieved in different ways. For these protocols the network management function will generate a substitute value to take the place of the “missing” port.
In acting to separate the secure network from the insecure network and ensure the security of the secure network, the firewall provides three types of transaction regulated by the filter, as follows:                “Local Call”: voice/data call initiated by a source in the secure network and terminated at a destination in the same secure network;        “Outgoing Non-Local Call”: voice/data call initiated by a source in the secure network and terminated at a destination in the insecure network;        “Incoming Non-Local Call”: voice/data call initiated by a source in the insecure network and terminated at a destination inside the secure network.        
It will be noted that two-thirds of all transactions types will have a node within the secure network identified in the source address. Each call/session transfers packets in both directions, so even if there were no local calls, half of the packets would have the secure network number in the IP Source Address Field.
The conventional approach to tracking the source for a succession of fragments associated with a particular packet is centred on processing in software. However, such implementations are slow due to processing bottlenecks.